1. Field of the Invention
This invention generally relates to object-oriented software environment and, more particularly, to a stateless-object method for executing programmable instructions.
2. Description of the Related Art
As noted in U.S. Pat. No. 6,134,559, Brumme et al., an object-oriented approach to programming provides advantages over conventional procedural programming approaches. For example, an object-oriented approach permits code reuse through inheritance, and modularity through encapsulation. There are many views as to what concepts define object oriented programming, and there are many terms and definitions for defining these concepts. In general, objects incorporate procedures, also called methods or operations, and data, also called attributes or properties. Objects are instantiated from, and described by structures known as classes or types. A class is a general abstract specification, and an object instantiated from a class is a specific concrete instance of the class.
A class consists of an interface and an implementation. The interface comprises variables and function declarations, wherein the variables represent the attributes of the type, and the function declarations specify methods for manipulating those attributes as well as performing other operations. The declaration specifies the name, return type, and argument, known collectively as the signature. The implementation refers to the actual code that implements the methods specified in the interface.
Object-oriented languages, such as the C++ language, permit the creation of special classes via inheritance. In general, inheritance is a mechanism for passing attributes and methods from a parent or base class to one or more child or derived classes. Inheritance permits code reuse because interfaces and implementations need not be duplicated in the child class. Instead, the interfaces and implementations may be incorporated in any child class through reference of the parent or base class.
In general, objects communicate through message passing mechanisms. An object, known as a client object, may call a method of another object. A client object invokes a method of another object by accessing the object via the defined interfaces. Thus, to invoke a method in an object or to query an object, the client object requires knowledge of the signatures of the methods in the interface of the target object. The client object calls the methods and passes the appropriate parameters. For example, to obtain the value of an attribute in an object, a client object calls a method, via an interface, to obtain the value.
As noted in US Publication 2004/0177093, Mullins, a frequent approach for accessing data stores involves writing and embedding custom access code within an object application needing the access. This approach is generally limited to having the custom code access only a single relational table within a relational database or similar construct within any other data store. Under the circumstances where a developer has control over the design and creation of a data store from its inception, it is possible to design and store meaningful information in a single table. Such design opportunities are usually rare, however.
Generally, the methods for producing persistence for a data object, complex data object, or a data store conflict with the goals of producing pure object application models where the object models do not include persistence objects or persistence byte code. Particular difficulties exist in a distributed environment since an object application model may exist in one or more of a computer's memory, an application data store and an application information storage repository that may be independent of the data store organization or object definitions.
Persistence problems arise with the creation, access, changing, or deleting of an object application model that utilizes data stores. The object application model may be distributed over multiple physical computer machine locations or even distributed over multiple Internet website locations that may be independent of the data stores. The object application model may utilize a different set of data objects or different set of definitions for relationships between data objects than that of one or more of its data sources. In most situations, the respective structures of the data sources and of the object applications model simply do not conveniently allow for mapping, accessing, or changing of an overall schema of application data objects as well as any associated definitions of relationships between two or more data objects or elements within a data object.
Relationships may exist between a data object and one or more of the other data objects found in the object application model or in a data object of the data source. A relationship between one data object and another data object or with a data source may be member selected from the group of three relationship types consisting of 1 to 1 (1-1), 1 to many (1-M) or many to many (M-M). Complex combinations of these relationships may exist as a data object relationships definition for a given data object.
Objects may logically span multiple relational tables or multiple object databases, and may even be distributed over a logical computer system involving multiple physically independent computer systems or even multiple website locations. Creating, accessing, maintaining or updating an object application model can require working with multiple translation modules and require tedious and repetitive updating of multiple individual computer systems or multiple data sources in order to do useful work and keep the object application model synchronized. Such approaches are both costly and unwieldy in terms of computing and development resources.
Data objects of an object application model are often a feature of an object programming applications, where information is obtained from a data source and the data is defined as a data object (e.g., as a JAVA class) for use with another computer application. In practice, a data object or model of data objects may exist only in the random access memory of a computer memory system, or may be saved to either a data source or to some other type of retrievable information repository. A programmer or administrator of an object data application cannot easily access or track the overall model or diagram of data objects for an object application model or some of its specific elements. Unfortunately, tools for accessing and persisting data objects and associated data object relationships of a complex data object graph model have not been well implemented in the field of object language programming.
A computer application can execute one or more of the following non-limiting actions with respect to one or more of the members selected from the group consisting of data, a data object, and a data object definition: access data, change data, create data, create a new relationship between one or more data objects by creating or changing at least one data object relationship definition, change or delete a relationship between one or more data objects by changing or deleting at least one data object relationship definition, access a data object relationship definition and use its parameters to access a data source or a data object, and access one or more data object relationship definitions or data objects to create a new data object or data object relationship. Any changes executed by a computer application with respect to one or more of the members selected from the group consisting of data, data object or data object definition may need to be properly persisted (permanently stored) to preserve any changes to one or more of the members selected from the group consisting of data, a data object and a data object definition.
“Instance” as referred to herein is a single occurrence of a software logical element in the memory of a computer system, such as a “class”, an “object”, a “data object”, and the like. This is analogous to the occurrence of a logical memory unit representing a row of data in common practice. “Class” as referred to herein is a logic unit in a computer application or a computer software program where the application or program is based upon an objected oriented programming language (e.g., JAVA). In practice, a class is a logical unit used as a logical template in an object oriented language from which to allocate new instances of objects. “Object” as used herein is a general term referring to a logic unit in a computer application or a computer software program where the application or program is based upon an object-oriented programming language (e.g., JAVA). The term “object” may ordinarily be used interchangeably with the term “class” as a template or as an instance depending on the context. As used herein, “Data object” represents the concept of the occurrence of an object that holds data within a specific computer application domain and is likely to have its contents stored in a persistent data source of a computer system (e.g., a database server, a binary file, a text file, or even in a combination of two or more of such a persistent data sources of a computer system). A data object may exist as an independent data object without any relationship to any other data object or it may have one or more relationships with itself or with one or more other data objects. “Navigation”, “navigating” or “navigated” refers to an action implementing at least one object to interact with a set of related objects for a certain purpose, such as creation, access, insertion, modification and deletion of an object, or of one of its relationships.
As noted above, many software systems are modeled using object-oriented methodologies, where objects represent real-world objects in the problem domain. These modeled objects possess methods and information about the object, referred to as “state”. State data can be, for example, the object's name, its color, or its location. The actual state information is stored within the object itself Therefore, if the user of the system creates two objects, both representing the same physical object, it is possible to change the state of one object, while leaving the other object's state unchanged. This results in the problem of having an inconsistency between multiple modeled objects' state information. This is usually addressed by maintaining complex relationships between objects to ensure that the user gets a reference to the same existing object and, therefore, the same state. In systems where the lifetime of the objects depends on those external references, it becomes quite difficult to manage the lifetime correctly, to avoid circular references, to persist the system state, or to minimize the working set of the application.
System persistence becomes difficult because each object must save its state, but also, the complex relationships between objects must be persisted as well. This problem is usually addressed by giving each object unique identifiers, and persisting references to the same object as the object's identifier. But a framework must be in place to support this as transparently as possible to the user. This issue also applies to remote objects, because all the dependent objects must be remoted as well. Also, since the entire graph of objects is eventually instantiated during the system's lifetime, the working set in memory can become quite large.
It would be advantageous if programmable instructions could distinguish and manipulate an object's state, apart from the object itself